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This note serves as a brief correction to several fundamental errors in 
RFC 567 by L. Peter Deutsch. 


t; 


Not all packets are 1000 bits long. This is basic to the network 
design. 


RFNMs are 152 bits long (72 bits of hardware framing and 80 bits of 
software identification and addressing). Host Host protocol messages 
such as single-characters and allocates are 216 bits long (40 bits 
of Host protocol, 8 bits for the character or ALL, and an additional 
16 bits of IMP software header). This totals to 736 bits in each 
direction, not 4000. 


The number of single-character messages that can be supported is 
therefore over 200 per second, not 37.5 per second. Not only is 
such a traffic pattern unlikely, but it can be supported in the IMP 
subnetwork much more readily than in most Hosts. 


Furthermore, if the demand for remote echoing ever exceeds network 
capacity, the TIPs and Hosts can simply buffer 2 characters per 
message, doubling the effective bandwidth of the network. Of 
course, dozens of characters can be packed into a single message 
with nearly proportional increases in effective bandwidth, given the 
size of the overhead. This buffering happens automatically and 
incrementally with increasing load as the natural consequence of 
slowed responses. 


It is most likely that the poor echoing response cited by Deutsch is 
not caused by peak network loads. If echoing was coming in 5- 
character bursts, there would have to be _1000_ characters per 
second coming from users of remote-echo systems to use all the 
capacity of 3 50-kilobit paths. 


This reasoning points up the more serious error in RFC 567: the 
problems associated with bad echo response are delay problems, not 
bandwidth. In designing the IMP software, we have used a bimodal 
model of traffic, and attempted to provide low delay for interactive 
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traffic, and high throughput rates for bulk data transfers. It is 


pointless to try for high data rates with short messages - the 
overhead in bits, and also in IMP and Host processor wake-ups, is 
too high. The primary factor in echoing performance is delay. As 
an extreme example, echoing over a megabit per second satellite link 
will lag a second or more behind input, with no bandwidth 
limitations at all. 


7. We agree that changes to TELNET protocol may well improve 
performance by reducing network traffic, and, more importantly, 
reducing demands for Host processing. In cases of network paths 
with long delay, especially satellite links, such changes are 
essential for interactive echoing. 
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